home *** CD-ROM | disk | FTP | other *** search
/ Collection of Tools & Utilities / Collection of Tools and Utilities.iso / asmutil / d86v322.zip / D08.DOC < prev    next >
Text File  |  1989-07-14  |  4KB  |  107 lines
  1. CHAPTER 8   COMMONLY ASKED QUESTIONS
  2.  
  3.  
  4. Setting Registers
  5.  
  6. Q: Why isn't there a debugger command to modify register
  7.    settings?
  8.  
  9. A: You can do so with an immediate assembly language command. For
  10.    example, to set the AX register to 100 type MOV AX,100  You
  11.    can now also set segment registers this way: MOV DS,0 REMEMBER
  12.    that if there isn't a leading zero, all constants fed to D86
  13.    are assumed to be decimal.  If you want hex constants, supply
  14.    a leading zero.
  15.  
  16. Q: How do you reset the CS register?  MOV CS,value doesn't work.
  17.  
  18. A: You issue a far JMP instruction to be executed immediately.
  19.    For example, to set CS to 0 and IP to 400 hex, type JMP 0:0400
  20.  
  21.  
  22.  
  23. Modifying Memory
  24.  
  25. Q: Why aren't there commands for changing memory to different hex
  26.    values, or for filling memory with a given value?
  27.  
  28. A: You can do this very effectively with D86's patch memory mode.
  29.    Just issue an immediate JMP to the location you want modified,
  30.    press the F7 key to enter patch-memory mode, and then issue
  31.    any A86 directive to initialize memory: DB for bytes, DW for
  32.    words, DD for doublewords, etc.  Remember, you have the full
  33.    power of the A86 language at your disposal.  You can provide
  34.    lists of values on a single line:
  35.  
  36.    DW 0100,0101,MY_SYMBOL
  37.  
  38.    You can make ASCII initializations with strings on DB lines:
  39.  
  40.    DB 'This is a string',0D,0A,0
  41.  
  42.    You can use the DUP construct to fill memory with a given
  43.    value or sequence of values:
  44.  
  45.    DB 100 DUP 0, 10 DUP (1,2,3)
  46.  
  47.  
  48. Screen Problems
  49.  
  50. Q: My debugger screen gets corrupted whenever the program being
  51.    debugged outputs to the console.  What can I do about it?
  52.                                                               8-2
  53.  
  54. A: This problem exists because D86 cannot quickly refresh the
  55.    screen on computers using the CGA (Color Graphics Adaptor)
  56.    video interface, without filling the screen with annoying
  57.    "snow".  So on a CGA computer D86 tries to keep track of what
  58.    it has output, and refresh only the parts of the screen that
  59.    have changed.  The strategy fails if the program itself
  60.    changes the screen.  You can restore a trashed screen by
  61.    pressing the Alt-F9 key.
  62.  
  63.    I haven't had the chance yet to implement a more sophisticated
  64.    screen interface, allowing you to switch between the program's
  65.    and the debugger's screen.  Until I do, you have these
  66.    options:
  67.  
  68.    * You can keep pressing Alt-F9 a lot.
  69.  
  70.    * If your program is making simple, teletype-style outputs
  71.      using MS-DOS function calls, you can redirect standard
  72.      output to your printer for the debugging session.
  73.  
  74.    * If you're really doing serious development of a
  75.      heavily-video program, you should consider getting a second,
  76.      monochrome-interface monitor for your computer.  Starting
  77.      from your CGA display, invoke D86 with the +V option.  D86
  78.      will come up on your monochrome monitor, but the program's
  79.      cursor will remain on the CGA monitor.
  80.  
  81.  
  82. Debugging ROM
  83.  
  84. Q: I tried stepping into a ROM BIOS routine.  It worked for a
  85.    while, but when I got to a certain instruction and stepped,
  86.    the computer crashed.  What's wrong?
  87.  
  88. A: My official policy on stepping into ROM is, "all bets are
  89.    off".  D86 does better than many debuggers at stepping into
  90.    ROM, but there are still some fairly insurmountable problems.
  91.    First, D86 itself calls the BIOS.  Not all BIOS routines are
  92.    reentrant; you could get unfortunate interactions between the
  93.    call being stepped and calls made by D86 while you are
  94.    stepping.  Second, ROM cannot be modified and hence traps
  95.    cannot be set within ROM.  D86 doesn't try to detect failed
  96.    trap-setting, so the program may be set loose in situations
  97.    where D86 thinks (and you think) it will retain control.
  98.  
  99.    This will always happen if you try the F2 key in ROM.  It will
  100.    also happen if you try to use the F1 key on an instruction
  101.    that loads a segment register.  For arcane reasons, the
  102.    single-stepping feature built into the 8088 doesn't work on
  103.    such instructions, so D86 must single step them with a trap.
  104.    Thus, F1 on a segment-loading instruction in ROM will set the
  105.    program loose.
  106.  
  107.